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interfaces for interaction with users; as a result, introductory 
comput er s c i ence courses must begin to t each the principles 
underlying such interfaces. This paper presents an approach to 
graphical user interface (GUI) implementat ion that is simple enough 
for beginning students to understand, yet rich enough to demonstrate 
many important aspects of computer science. The GUI interface 
described is implemented using a library of C macros and provides a 
display window that outputs bit-mapped graphics and inputs mouse 
actions. The macro calls and conventions are described in the context 
of an implementation of Conway *s Game of Life, a programming exercise 
found in many introductory texts. The GUI interface for trhe Game of 
Life program is detailed in the first section, in order to provide a 
concrete example of the capabilities of the simplified GUI library. 
The next section describes the life main function that sets up the 
buttons and associated callback functions; these callback functions 
are then presented. The last section gives an example of a simple 
paint program th?' can also be created using the GUI macro library. 

In addition, this paper considers how the material could be 
introduced in an Introduction to Computer Science course at 
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Abstract 

Modem computing systems exploit graphical user interfaces for interaction with users. As a result, introductory com- 
puter science courses must begin to teach the principles underlying such interfaces. This paper presents an approach to 
graphical user interface implementation that is simple enough for beginning students to understand, yet rich enough to 
demonstrate many important concepts and trade-offs in computer science. 

introduction 

A major problem confronting teachers of introductory computer science courses is that, while most computational 
environments that students are exposed to involve graphical user interfaces (GUIs), the I/O programming paradigm that mey 
are typically introduced to is character based. The irony is that students are using and en:oying the flexibility of GUIs but from 
a programming point of view they could just as well be using teletype machines. It is clearly no longer acceptable to give 
students programming exercises where graphical information is output as lines of ASCII characters. Further, students re- 
stricted to character-based input quickly become bound up in the intricacies of awkward command languages, when a GUI 
interface would be more natural. At the same time, there are valid reasons for hesitating to teach GUI programming at the 
introductory level. Foremost is the additional complexity involved in doing event-loop programming, typically considered too 
difficult for the novice programmer. 

While a strong case can be made for introducing GUI programming techniques into introductory computer science 
courses, this is not being done. The only introductory Computer Science text (of which we are aware) that integrates bit- 
mapped graphics is Roberts (1995). By including a graphics.h file in the C code, the programmer has access to a set of basic 
functions for producing bit-mapped output, e.g., MovePen, DrawLine, Draw Arc. We are not aware of any introductory text (or 

course) that attempts to introduce both GUI input and output. 

This paper will describe a simplified GUI interface that is implemented using a library of C macros and provides a 
display window that outputs bit-mapped graphics and inputs mouse actions. The input mouse actions can be used in a 
drawing framework and for the control of some (user specified) number of input buttons. The library of macros supports t u 
MOTIF GUI interface standard, but could easily be converted to support other GUI standards. The macro calls and conven- 
tions will be described in the context of an implementation of Conway's Game of Life (Conway, 1970), a programming exercise 
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found in many introductory texts. The macro library has been used in teaching the second computer science course at 
Rensselaer. The positive reactions of students have indicated to us that introducing this library to students in the course 
Introduction to Computer Science (CSl) would enhance this course as well. This paper will describe how this material could 
be introduced in CSl. 

The GUI interface for the Game of Life program will be described in the first section, in order to provide a concrete 
example of the various capabilities of the simplified GUI library. The next section describes the life main() function that sets up 
the buttons and associated callback functions. The callback functions (and macro conventions for calling them) that are at the 
heart of the programming interface support are presented in the next section. The last section gives an example of a simple 
paint program that can also he creating using the GUI macro library. In all of these sections we consider how' this material 
should be presented to CSl students. 

The Game of Life and its GUI interface 

In general, the GUI interface (as supported by the macro library) provides two regions of interaction with the program: a 
vertical strip of user definable buttons on the left and a larger display /drawing region to the right. For example, when the 
Game of Life program is invoked a window like that shown in Figure 1 appears on the screen. In the Game of Life, the 
graphical display / drawing region may initially be all black, indicating that there are no live cells. The user can then drag the 
mouse in this region in order to draw in the cells (in white) that are considered to be alive. The Game of Life transition can 
now be applied to the initial array of live cells. 

Basically, the Game of Life transition embodies simple rules of population support and crowding. For example, live cells 
stay alive if they are "sustained'' by "just the right" (2 or 3) immediate neighboring cells that are alive, but if a live ceil is 
crow^ded (4 or more neighbors) or too isolated (0 or 1 neighbors) then it dies. Similarly, cells can come to life if they have just 
the right support in their neighborhoods. WTiat is interesting about this simple "game" is that a variety of stable configurations 
of "cooperating" cells tend to emerge, when successive transitions are applied to initial random configurations. 




Figure 1. User initialized state of the GUI Game of Life interface 

The user moves back and forth between changing states in the array using the mouse and clicking the "STEP" button to 
move the transition function ahead. The "PUT" and "REMOVE" buttons are used to toggle the effect of dragging the mouse 
across the graphics window: the "PUT" button sets a global variable that results in mouse movements bringing dead cells to 
life, while the "REMOVE" button sets the global variable so that live cells are removed as the mouse is dragged across the 
graphics window. The "DELTA" button causes program control to return to the standard input UNIX window, where the user 
is queried as to the number of generations to be computed whenever the "STEP" button is pressed. The default number of 
iterations is one. By setting the number of iterations to a value other than the default, the user creates the effect of animating 
the Game of Life transitions. Finally, the "QUIT" button is automatically supplied by the macro library and provides a means 
of exiting the program via the GUI interface (a controLC in the UNIX text window can also be used to exit the program). 

When the Game of Life program is invoked the user may specify (via command line arguments) a file that initializes the 
array of live cells. In addition, the user can specify from standard input a sequence of coordinates of initially alive cells. The 
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third mode of input (as described above) is via the mouse in the display/drawin); region. We feel that the students benefit 
from exposure to all three modes of input. They need to see that a natural way to input cell states is via a mouse, but that 
sometimes a larger or algorithmically generated ASCII input file is more appropriate (e.g., as might be generated via a random 
initialization program) or that sometimes entering a few specific coordinates of alive cells is more natural (e.g., during 
debugging). We introduce more on UNIX filters and pipes than is typically covered in CSl and compensate by covering 
named file I/O somewhat less. In addition, while pointers are not usually covered in CSl we introduce them in the context of 
processing command line parameters (via argv and argc); that is, pointers arc introduced solely for simple string manipula- 
tion, e.g., the students learn that argv[l] points to the string of characters comprising the first command line argument, which 
in turn makes a fine argument to fopen. We view it as an important general intellectual lesson that students appreciate how 
limiting I/O to a serial stream of characters is a strong intellectual restriction and, as such, at times is a significant limitation 
and at other times is a useful simplification of complexity. Thus, we are careful to ensure that students come away with some 
idea of key I/O trade-offs, as opposed to thinking that a GUI is always the best option or conversely that ASCII (standard or 
file) input is the only option. Finally, throughout the computation there is the option of co'nmunicating with the user \ ia a 
stream of ASCII characters. This allowed us to choose a "minimal" set of GUI primitive; to support via the macro library: a 
vertical array of buttons on the left and a display/ dra.. ;ng region to the right. With the c inability to communicate with a user 
via buttons, a display /drawing region and standard I/O window we believe that there is sufficient coverage of the basic 
modalities of modern I/O interaction. 

One reason that the Game of Life is often given as a programming example in many introductory texts is that it is 
inherently fascinating. At the same time, we have argued that a lack of true GUI programming makes interacting with one's 
program a frustrating experience. Bevond this issue, we often find th-i.t too many of the programming exercises in introductory 
texts are given in isolation and precious little is given concerning the larger scientific issues. Thus, students leave the isolated 
Game of Life exercise with a sense that it is "neat," but little more. In the CSl course that we are teaching, we are approaching 
the teaching of this material via an integration w'ith extensive case studies. The GUI toolkit is part of a larger project to develop 
an online hypermedia textbook (Skolnick & Spooner 1994) for introductory computer science courses for both majors and non- 
majors. This hypermedia textbook combines science and engineering case studies with w'orkstation-based computing concepts 
and tools to provide students with the computing knowledge they need to successfully apply computing in their own disci- 
plines. In the case of the Game of Life, it is a simple exercise to consider other variations on neighborhood transition functions, 
e.g., parity, min, average, max. This allows us to consider how- these kinds of neighborhood cellular array cc.nputations are 
being used in areas such as image processing and as alternative scientific models of physical systems, e.g., in Toffoli and 
Margolus (1987) various kinds of neighborhood transitions are used to model basic thermodynamic systems. We can also 
approach more profound issues related to the nature of computation itself, i.e., w'hen considering how' to generalize the 
neighborhood transition function it is natural to consider the class of all such boolean functions, which leads to such issues as 
combinatorial explosion, search spaces, computational completeness and haalware boolean 'ookup tables. 

We now consider how' the GUI functionality is implemented at the programming le\ el and w'ill discuss the additional 
concepts that need to be introduced in CSl to allow students to understand the basics of e\ ent-k<op programming. 

main() routine in GUi Life 

Before considering the details of the code, it is useful to describe how the basic ideas of event-loop programming are 
presented to the students. The students are told that the event-loop program can be viewed as a mini-operating system, which 
Lndles much of the tedious details of the GUI interface. When a programmer wants to define a button, a function call must be 
made to the e\ ent-loop program. Certain essential information about the button must be passed to the event-loop program: 
the name to appear on the button and the name of the callback function to be in\ oked when the button is pressed. The e\ ent 
loop places the buttons onto the screen, detects which butt-n is being pressed, graphically represents button presses and, most 
important to the programmer, transfers control to the appropriate callback function to process the actions assocateo with the 
button. Students are told that there are many different types of interface objects (widgets) that can be created, but we have 
provided a simple default class of such objects. They need only visualize the event-loop program as something they communi- 
cate with initially from within their main() routine and then the final action within main() is to transfer control to the e\ ent- 
loop, which will then be responsible for in\ oking the callback functions (defined by the programmer) in response to user 
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How these issues arc handled at the programming level can be seen in the main() program in higure All the Motit 
macro definitions and related global variables are defined in the main_gui.h include file. In the figure, macro calls are indi- 
cated bv all upper case names and the absence of semi-colons at the end of the line. Since we use ANSI C, the function 
prototypes of the four user defined button callback functions are setup using DEF_BUTTON_FUNCS. (Some example callback 
function definitions will be considered below.) The purpose of the DEF_BUTTON_FUNCS macro is to hide some of the messy 
details of the Motif library, e g., the expansion of the macro will result in the following prototype definition for the step 
function, "void step(Widget, Widget, XmPushButtonCallbackStruct *);". In general, we believe that there is benefit in covering 
macros more thoroughly and earlier in a CSl course than is tvpicallv done (e.g., beyond #defines), since macros can be used to 
introduce basic functionality early on, providing a useful foil for the more intricate explanations of true functions and param- 
eter passing. After processing anv command line arguments-in FarseArgs-the first macro call, SI'.TL!I’_MOTII _WII9GLTS, 
generates in the main program all the appropriate general widget definitions for the GUI interface. The four calls to the 
CREATE_BUTTON macro result-from the students point of view-in the event loop having all the necessarv information for 
managing the buttons, i.e., the names of the buttons and the associated callback functions. Next, the call to 
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CREATE_WINDOWS results in the GUI interface window appearing on the screen, with the four user defined buttons (and 
the default '"quit" button) and an initially empty display /draw window to the right of the buttons. The InitWindow function 
is called to see if the user has specified (via command line arguments) a file that initializes the array of live cells. 



#include "life.h" 

#include "main_gui . h" 

DEF_BUTTON_FUNCS (Step, put, 
remove, delta) 

void main(int argc, char *argv[]) 

{ 

ParseArgs ( &argc , argv) ; 

SETUP_MOTIF_WIDGETS 
CREATE_BUTTON ("STEP", step) 
CREATE_BUTTON ("PUT" , put ) 
CREATE_BUTTON ("REMOVE", remove) 
CREATE_BUTTON ( "DELTA" , delta) 
CREATE_WINDOWS 

InitWindow ( ) ; 

TRANSFER_TO_EVENT_LOOP 

} 



Figure 2. The main() function of the Game of Life program. 



The final macro call in main() is TRANSFER_TO_EVENT_LOOP, which turns o\ er . ontrol to the event loop. This 
movement away from control residing in the maih() program is exhilarating to many students but can be confusing to others. 
We find that this transition is smoother if students are introduced to programming from the very start within the context of a 
symbolic debugger (which we tell the students to view as the symbolic "inspector"-our attempt to counter the "pathological" 
perspective that debuggers are only useful when things don't work). Thus, since students are familiar with the notions 
successive refinement and "plug" functions, they can verify in the "inspector" that when a button is pressed the associated 
callback function is indeed invoked. 

We now briefly consider button callback functions followed by the callback function associated with mouse events in the 
display/draw portion of the GUI window. 

Callback Functions 

The simplest class of callback functions are those associated with buttons, because there is no information that needs [o 
be passed by the event loop to the function. The callback function is simply called when a button is pushed. One (of the four) 
Game of Life callback functions is given in Figure 3. Note again the use of macro substitutions to hide some of the messv and 
irrelevant Motif parameters, e.g., BUTTON_ARGS. 

The step function (in Figure 3) does the main work of the computation, determining the next generation ol alive and 
dead cells (ComputeNextGeneration) and then updating the current generation and displaying any altered cells 
(CopyNextToCurrent). The parameters passed to these two functions-<urrent_gen and next_gen-are arravs containing the 
information on alive and dead cells. Information on the programming interface for displaving the cells is given below in our 
discussion of the callback routine for the display /draw component of the GUI interface. 

void step (BUTTON_ARG$ 
computes and displays the next 
sequence of generations */ 

extein int Num 1 1 erat i ons / 
int i; 

for (i^O; KNumIterat ions; i + ^) { 
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} 



ComputeNext Gene rat ion { cur rent _gen , 
next_gen) ; 

CopyNextToCurrent (next_gen, 
current_gen) ; 



Figure 3. Two of the four button callback functions. 

We now turn to the display callback function associated with actions in the graphical display/draw window. The 
displav/draw window is where the graphical information is displayed as well as where the mouse events (used to set cells to 
be alive or dead) are detected. The display callback function, which handles responses to mouse events, is shown m Figure , 
Students are expected to have a display_callback function defined somewhere in their source file (or files). Thus, it is a special 
reserved function name that currently is "hardwired" in ttie gui,h macro library. It is invoked whenever a mouse down, mouse 
drag or mouse up event is sensed by 'the exent loop. Note also that the gui_extems,h file contains all external references to the 
GUI variables that are defined in main() and any GUI macros that might be invoked by any function. . , , 

We have provided several macro definitions that allow the programmer to access mouse event information. In ..le 
display callback function for GUI life, MOUSE_X and MOUSE_Y result respectively in the current x and y ™«rd.nates of the 
mouse. One of the arguments passed to display_callback (and defined in DISPLAY_CALLBACK_ARGS) is^ XButtonEvent 
* event"* event is a pointer to the relevant mouse information. Thus, MOUSE^X is defined as _event->x. These kinds of 
macro definitions allow postponement of detailed explanations of pointers to structures until students are ready; when they 
are ready for this material they enjoy unfolding the meaning of the code generated by the macros. 



# include 
# include 
# inc lude 



"life. h" 

" 1 i f e_externs" 
"gui_externs . h" 



void 

display callback (D Ic 3 PLAY__CALLBACK_ARGS) 

int x,y; /* up-left corner of cell */ 
int rov;, col; 

V = M0USE_X- (MOUSE _X . Pixels_per 
y = MGUSE^Y- (M0U3E_Y Pixels_per 
row •-"- y / Pixels_per_cell ; 
col -- X / Pixels/per^ce". I ; 
if (DrawingCells) { 

XFi 1 IRectangle (DISPLAY^WIN, x, 

P ixels_per_cel 1 , Pixels_per 
XFillRectangle (DISPLAY_BUF, x, 
Pixels_per_cel 1 , Pixels_per 
cur rent _gen I row ] [col] = ALIVE; 

else { erasing cells */ 
SET_FOREGROUND_BLACK 
XFi 11 Rectangle (DISPLAY_WIN, x, y, 

Pixels per cell, Pixels_per_cell); 
XF L 1 IRectangle (D1SFLAY_EUF, x, y, 

Pixels per cell, p i xel s_per__ce 1 1 ) ; 
SET _FOREGROUNL_WH I TF 
ruiicnt. uen 1 rov;] [ col ] " DEAD; 



cell) ; 
cell) ; 



cell) ; 
Yf 

cell) ; 
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} 

DISPLAY_WINDOW 

} /* end of display_callback */ 



Figure 4. The display_callback function for the game of life GUI, 



The first two executable lines of code in display_callback (Figure 4) compute the x and y coordinates of the upper- 
rightmost pixel of the rectangular region that represents the cell. The next two lines in the code compute the row and column 
of the cell where the mouse w'as clicked. If the user has set the mode to DrawingCells, the mouse click will result in a white 
rectangle being drawn on the screen and current_gen array that records alive and dead cells being updated. There are two 
calls lo XFi II Rectangle, which is the X Window function that draws the live cell as a whitt rectangle. The two calls to 
XFillRectangle are required because it is necessary to support two display buffers: DISPLAY_WIN refers to the display buffer 
containing the actual information being displayed, while DISFLAY_BUF refers to a "backup" buffer typically containing the 
same information. The reason for the two buffers is to deal with the rcfresh problem in windowing systems: whenever the 
current information in DISPLAY_WIN is written over by another window, there must be a "backup" buffer which is used to 
restore the window information when the covered window is made active again. Introducing this complexity in supporting 
GUI programming is necessary but students can be initially told to always have two invocations of any graphics routine, one 
to each buffer. (We will consider below how this additional complexity has some advantages in other settings.) There seems to 
be little problem in the students appreciating that if they don't write to DISPLAY_BUF (in addition to DISPLAY^WIN) then 
they will loose the information in the GUI display/ draw window when it gets covered by some other window. Also, all of the 
internal details of handling this refresh issue are implemented within the macro library, so the students need not be concerned 
with any further implementation details. Another point concerning the design of the macro library is that there is an advan- 
tage in not hiding the fact that XFillRectangle is being called, e.g., by hiding it in a macro call or even condensing the two calls 
to XFillRectangle into one macro. We want to avoid the danger of abusing macros by creating an idiosyncratic version of C. In 
addition, there is a significant advantage in introducing students to the level of XWindow calls because they can then go to the 
manuals and discover many other useful graphics routines, e.g., XDrawLines, XDrawPoints, etc. It seems to us that we need to 
prepare CSl students with knowledge that allows them to enter into deeper levels of system documentation. CSl texts and 
courses have tended to ignore this issue. 

One other application: a paint program 

With the basic mechanisms of the macro library behind us, we would like to consider one final programming project that 
now falls within the range of a CSl course. Figure 5 shows the screen produced by a simple paint program. The structure of 
the program follows that of the Game of Life program, with calls to XDrawLine and XDrawRectangle being made within 
display_callback. The "RFCT" and "FREE" buttons set a global variable that determines the effect of mouse actions in the 
display /draw window. 




Figure 5. A sample screen of the paint program written using the macro library. 
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It is also worth uoUng that the double buffering scheme described above-involving DISPLAY_WIN and DISPLAY.BUF- 
has the advantage of allowing the animation of rectangle drawing motions, as well as more general animation effects. All 
students are expected to be able to program a simple non-animated draw function where, (1) an initial mouse down event 
(tested for via a MOUSE_IX)WN macro predicate and associated with the left mouse button) positions the upper left comer of 
the rectangle, (2) mouse movement events (tested for via a MOUSE_MOVE macro predicate) result in no display changes, and 
(3) a final MOUSE_UP event (also tested for via a macro predicate) positions the lower right comer of the rectangle so that the 
rectangle can then be drawn with calls to XDrawRectangle. As a more difficult programming problem students may consider 
how to animate the draw, as is done in most drawing programs. This is accomplished by maintaining the state of the wmdow 
prior to the mouse down event in DISPLAY_BUF and whenever a mouse movement is detected, DISPLAY_BUF is copied into 
DISPLAY WIN and the rectangle defined by the current mouse position is drawn into DISPLAY_WIN. The effect is that as the 
mouse is dragged across the screen, the rectangle associated with the previous mouse position is erased and a new one is 
drawn. If the speed of buffer transfer is well matched to the speed at which the mouse is drawn across the screen, the effect is a 
smooth animation of the drawing. Students are truly amazed that such animation effects are within their programming skills 
and gain an appreciation of some basic tradeoffs between CPU power and the complexity of events that can be handled in a 
GUI interface. 

Conclusion 

In summary, the use of a simple GUI toolkit for teaching programming in an introductory computer science course otters 
several important advantages. It provides an exciting opportunity for students to exploit the newest hinctionality of modern 
computing technology, thereby increasing their interest and motivation to learn and experiment. It facilitates pre^ntation of 
design and interface issues. And it allows students to begin to appreciate and understand the GUI components of the systems 
and application programs that they commonly use in other situations. 

The GUI toolkit is available via anonymous ftp at "ftp.cs.rpi.edu". Use "anonymous" as the user name and your email 
address as the password. Once connected, change to the directory "pub/ graphieslib". The "README" file m that directory 
contains the details of what is available and how to install and use it. In particular, the directory contains the macro library and 
sample code for the Game of Life and Paint programs. 
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